2.1. General time zone issues
2.1.1.
How should a client / server react towards existing meetings when a time zone rule changes? For example, if DST changes for a time zone, should the existing meetings created in that time zone be adjusted to the new rules or should they remain the same and let the changes be applied only to newly created events?
2.1.1.1.
In most cases, meetings created using a time zone should use the new time zone definition so that effected recurrences reflect the time zone change (Example: Lunch at noon every day). Cases where the timing has to be fixed should be created in UTC (Example: Enter a few digits on a terminal every 108 minutes), which has no dependency on time zone rules.
2.1.2.
How should a client / server handle a new time zone?
2.1.2.1.
If a client /server model is used, the server should have a means of updating the time zone list. This can be accomplished in many different ways such as keeping a checksum of the “current” time zone list; when that list changes on the server, clients simply re-download their local copies.
2.1.2.2.
If a PIM client is used (no server), a patch could be issued updating its time zone list.
2.1.3.
How should a client / server handle a time zone fork? (For example: if DST changes in the US only and not in Canada and meetings were created using an EST5EDT time zone). This could create two new time zones EST5EDT_CA for Canada and EST5EDT_US for the US (and deprecating EST5EDT).
2.1.3.1.
The GEO property might be used to detect which of the new time zones every meeting belongs in.
2.1.3.2.
The LOCATION property can also be used to detect the appropriate time zone for the meetings.
2.1.3.3.
If no information in the calendar object can be used to detect the appropriate new time zone, a default choice could be used based on where the majority of the meetings usually occur.